單篇的迴圈會把每一篇修到能看，但 Day 2 就警告過：多日系列的翻車發生在篇與篇之間，單篇迴圈根本看不見。所以檢驗階段的第一站是跨篇稽核。核心主張是：系列品質要跨篇檢查，而且檢查結果要能分流到「改文章」或「改計畫」。

先交代座標，免得誤導。本篇的位置是 Day 23，稽核對象照規劃是到此為止已經存在的初稿；但實際執行時，全系列 30 篇初稿都已在同一批產出，所以 2026-08-14 這一輪稽核的實際範圍是 30 篇全部初稿。以下是那一輪真的跑出來的結果，不是示意。

方法有三把尺，全部來自計畫欄位。第一把，遮編號互換測試：蓋住 Day 編號，兩篇能對調位置就是重複——new_value 有一格是空話。第二把，依賴實查：depends_on 說這天靠前面哪幾天，就去驗證那些概念真的在前文建立過，沒建立過就是斷裂。第三把，邊界巡邏：scope_boundary 說這天不准碰的東西，全文搜一遍有沒有偷碰——偷跑結論通常就藏在這裡。

第一把尺抓到兩件事，而且分流到不同層級。第一件判給「改文章」：Day 5 講盤點原則、Day 18 是同一件事的現場紀錄，計畫層的分工其實切得很乾淨；但兩篇的示範例子撞在一起了——都拿「pack-0.1.0.zip 真的拆開讀過」和「Release 查詢是空清單」當範例。病根不在計畫，在我兩次都挑了最順手的那兩個例子。處置是文章層改例：Day 5 換成聲音與交付兩個面向，Day 18 專收證據面向，計畫一個字都沒動。

第二件判給「改計畫」，但沒有立刻改。Day 9 講核准要綁 hash 的原理，Day 20 講舊核准如何失效的實錄——兩天原本都引用同一條測試 test_changed_plan_invalidates_approval 支撐同一個論點，這種重疊光改文章治不好，因為 new_value 在計畫層就沒切乾淨。可是改計畫會產生新 plan hash、需要重新走核准，而當前計畫本來就還卡在未核准；這時再推一版，只會讓閘門更亂。所以本輪的處置是：文章層先降低重疊（Day 9 只留原理，測試證據下放給 Day 20），計畫層的分工調整列為待處理事項，等老闆處理完當前核准再一併提出。稽核不是只有「馬上修」一種結論，「已定位、暫緩、附理由」也是。

第二把與第三把尺這輪沒有抓到問題，但沒抓到也要記。依賴實查：30 篇的 depends_on 逐條對照，每一篇開頭都接得住它宣告的前置日，沒有依賴前文未建立的概念。邊界巡邏：Day 1 至 4 明文禁止提前倒出 CLI 與檔案細節，全文掃過沒有違規；Day 17 與 Day 29 都出現同一個建置 hash，看起來像偷跑，細查後確認兩者回答的問題不同——一個問工具能不能重現，一個問出貨版本能不能核對——虛驚一場。把「查過、沒問題」記下來跟記問題一樣重要，不然下次稽核還會在同一個地方再疑神疑鬼一次。

分流的原則一句話：徵兆在文章，病根可能在計畫。同一個概念被兩天重講，改文章只能治標；反過來，depends_on 明明成立、只是後一篇開頭忘了接，那就是文章的活，別動計畫。

稽核不浪漫，它的產出是一張「哪裡查過、哪裡有病、病判給誰」的清單。但一套敢自稱系列的東西，總得有人隔著二十幾篇的距離回頭看一眼——這一眼，就是系列跟一堆文章的差別。